资深架构专家聊架构之道：规划、简化和演化

李晓时，超过 20 年 IT 行业经验；资深架构专家，《架构宝典》联合作者。

1

引言

大家好，我是李晓时，架构这个概念，和计算机科学（包括近几年才成为一级学科的软件工程）的其他术语类似，都是从传统学科借用来的。这是因为计算机科学太年轻、发展太快，来不及形成自己特有的术语和名词。因此，在学习和思考方法上，常常推荐类比法，尝试用一些耳熟能详的事物去理解和解释计算机科学领域的概念，以求“老妪能懂”的效果。

这里介绍的一些内容，大多是个人在学习和实践过程中的一些思考和体会，以及平时的一些学习笔记整理而成，还很不成体系，还有很多需要继续推敲的地方。我会在未来的工作实践中更加深入思考，广泛参考领域内的成果，力求概念准确，容易理解。也欢迎各位同行专家不吝赐教。

2

什么是架构

关于架构概念的学习和理解，我建议从 2 个方面入手：

第一、这个概念来自于建筑工程领域，要深入准确地理解，需要看一些建筑方面的资料，比如我会看梁思成《图像中国建筑史》手绘图，从中体会什么是架构；我也会到建筑工地去看建筑施工的一些情况；还会在旅游时有意识地关注不同样式的建筑，体会其架构的不同。“建筑是凝固的音乐”，我们要试图体会架构之美。

第二、对于计算机科学与工程实践中总结出来的一些架构，我们要通过实践来学习和领会。比如对于 MVC 架构，我们是否联想到用 VC++编程时 “ Document/View ” 模型？比如说到三层架构或者多层架构，我们是否考虑到与 “ Client/Server ” 二层架构的关系。

2.1

架构工作可能是隐式的

架构工作，不管有没有架构师被指派，其实都是会做的，只是有些时候，架构工作被做了，但没有人意识到。

有明确的架构师，可能会使架构工作更加专业化，可能对提高架构的质量有帮助；但并不是只有架构师才可以做架构工作。

我们应该把架构师当成一种角色，而不仅仅是一个头衔、一个位子。也许有很多人的工作头衔是架构师，但其实际工作和架构关系不大，也可能有些人没有架构师头衔，但其在实际工作中卫架构正在做贡献。

3

TOGAF 的企业架构模型

As shown in the figure, TOGAF divides an enterprise architecture into four categories, as follows:

图中，TOGAF 把企业架构分为 4 个部分：

1.Business architecture—Describes the processes the business uses to meet its goals

第一、业务架构。描述业务流程及其达成的业务目标。

2.Application architecture—Describes how specific applications are designed and how they interact with each other

第二、应用架构。描述具体的应用系统的设计以及相互之间的关系。

3.Data architecture—Describes how the enterprise datastores are organized and accessed

第三、数据架构。描述企业的数据存储以及访问方式。

4.Technical architecture—Describes the hardware and software infrastructure that supports applications and their interactions 第四、技术架构。描述基础设施如何支持应用系统的运行及交互。

其中，一个重要的理念是业务架构与应用架构的映射关系（依赖、推理）。应用架构要基于业务架构来考虑，而不是凭空想象。应用是业务能力的提供者。

3.1

与数据有关的三种角色

很多时候，IT 部门、以及 IT 部门的一些人，常常把自己当成数据的所有者，导致认为地制造了藩篱，阻碍数据的共享及访问。其实，IT 通常应该只是“司机”的角色。角色错位了，想做事正确？难于缘木求鱼。

这里强调数据，是因为数据是对客观世界的反映，而我们的每一个应用，不过是客观世界的一个视图。

数据是最基本的。数据可以被处理、解释而得到各种信息，而信息又可以被挖掘出有用的知识。我们也可以从中理解当今所谓 DT 的重要性，以及大数据时代，数据就像工业时代的石油一样重要。

4

架构的地位

架构是客观存在的，不管我们是否有意识地考虑它。架构不是孤立存在的，它是在具体的上下文环境中，为达到明确的目标而存在的。架构不是“屠龙术”。

“规划-架构-设计”这三者是紧密联系的，常常被混为一体的。为了理解这些概念的联系和区别，我们可以与市政规划进行类比。巴西利亚的建城史、华盛顿的城市规划，其理念值得我们在考虑架构时借鉴。

5

规划与架构

这里把规划提取出来，而不是与架构混为一谈，是为了有助于理解思考与实践的不同阶段和步骤，帮助思维更加清晰。从软件工程与建筑工程的类比，更容易地理解架构和规划。另外，“自顶向下，逐步细化”的结构化思想也清晰可见。我们推崇面向对象的方法，因为它与客观世界的实际情况更接近，同时，我们也要继承和发扬结构化方法。

6

架构与设计

所有的架构都是设计，但不是所有的设计都是架构。架构可以认为是宏观设计、顶层设计。

计算模式经历了几个发展阶段，我们选择什么的模式，一方面要跟上技术发展的趋势，另一方面要知道目的是什么。

第一、主机-终端（mainframe）第二、个人计算机（PC）第三、客户机/服务器（C/S）第四、分布式计算（网格、云计算等）

7

分布与集中

如果规模不大，采用分布式部署意义不大。

8

解耦与服务化

对解耦与服务化的关系进行深入思考，尝试理解其本质，明确什么事目的，什么是手段。在做决策的时候，就有助于分清主次。

8.1

一种不严格的解耦方法

对于企业应用架构向“微”服务演化，解耦是基础。为此，在程序实现时，“单一职责”原则需要尊循。即使不走服务化道路，降低耦合度也是好的。

是否可以假定：一般情况下，对于特定的语言环境，比如：java 和 C#，较少的代码行很难实现多个业务功能？于是以子程序(函数，过程，方法)代码行数对工程师执行“单一职责”原则进行度量。

对于不同语言，建议对开发小组的代码行进行统计，经过一段时间的积累得出合适的经验值。一般地，这个代码行数的经验值是和小组的能力相关的。

9

迭代/敏捷与传统方法

敏捷方法的使用离不开迭代，我们需要合理地使用这两种方法，才能使我们的交付物越来越逼近用户的真实需求。

这里提到了用户的真实需求，我也多说几句。用户的需求不应该是我们作为 BSA 或者 SME 假设出来的，而是我们通过各种有效的方法，比如访谈，从用户那里捕获的。即使我们对用户的建议是正确的，帮助用户完善需求的，也一定要取得用户的完全理解并由用户正式确认。

10

由分工引发的思考

没有分工，协作就是一句空话。没有明确的分工，就会造成扯皮等现象。分工有助于提高效率和质量。要想分工，就要做好功能分解。而功能分解到合适的粒度，也可以认为是服务化的基础。

微服务所倡导的“单一职责”，其实质也是明确责任，消除歧义。简单即美，大道至简。单一职责恰恰符合这个原则。

从这个对制造别针的分工的描述，你会体会到并发现，很多基本道理是相通的，不论对于生产制造还是软件开发。这就是道法自然。（未完待续）